How did you find that slow function (updateStatusWithDockerImageAndVersion)?

How did you find that slow function (updateStatusWithDockerImageAndVersion)?

operator was logging status updates for each broker every 5-15s

@azun - what do you think of adding condition on when a broker's kafka version needs to be rertrieved? I was thinking that the Kafka version doesn't change often and there are conditions we can implement to have it fetch it. This will reduce the need to retrieve on every reconcile.

Please check out this PR: #249

Overall, the PR looks good and will reduce the time to reconcile. Nice work.

Code Review — feature/reconcile-improvements

▎ Auto-generated pre-flight review · 5 files · 6 commits

🔴 HIGH — Label removal may break alertmanager-peerauthentication

charts/kafka-operator/templates/operator-deployment-with-webhook.yaml

The removed component: alertmanager label is used as a matchLabels selector in alertmanager-peerauthentication.yaml. After upgrade, the PeerAuthentication
resource will no longer match the operator pod, silently breaking permissive Istio mTLS in clusters with alertManager.permissivePeerAuthentication.create:
true. The app: prometheus removal may additionally break user-managed NetworkPolicy/PrometheusRule selectors.

Suggested fix: Add a NOTES.txt upgrade warning, or verify no active selectors depend on these labels before removing them.

🟡 MEDIUM — PodMonitor bypasses kube-rbac-proxy when both features are enabled

charts/kafka-operator/templates/podmonitor.yaml:29

The PodMonitor targets port: metrics (pod port 8080, plain HTTP). When authProxy.enabled: true (the default), this bypasses the RBAC proxy entirely — any
Prometheus with in-cluster access can scrape operator metrics without authorization. Both flags are opt-in, but the interaction is undocumented and creates a
non-obvious security misconfiguration.

Suggested fix: Add a Helm fail guard when both are enabled, or target port https (8443) with TLS/bearer-token config.

🟡 MEDIUM — PodMonitor missing outer prometheusMetrics.enabled guard

charts/kafka-operator/templates/podmonitor.yaml:1

Every other Prometheus template in this chart wraps its block with {{- if .Values.prometheusMetrics.enabled }}. The new PodMonitor only checks
prometheusMetrics.podMonitor.enabled, so it can render even when metrics are fully disabled — producing a PodMonitor pointing at a non-serving endpoint.

Suggested fix:
{{- if and .Values.prometheusMetrics.enabled .Values.prometheusMetrics.podMonitor.enabled }}

🔵 LOW — http.Client allocated per JMX call defeats connection pooling

pkg/jmxextractor/extractor.go:94

&http.Client{Timeout: 30 * time.Second} is constructed on every call. With the new concurrent goroutine-per-broker model, this spawns N independent clients
per reconcile cycle with no TCP connection reuse.

Suggested fix: Promote the client to a field on jmxExtractor, initialized once in NewJMXExtractor.

✅ Concurrency refactor looks correct

The goroutine-per-broker fan-out in updateStatusWithDockerImageAndVersion is sound: the channel is buffered to len(brokers) and each goroutine sends exactly
once, so there is no goroutine leak on early return. The JMX timeout fix is a clear improvement.